🦋 Changeset detected

Latest commit: b0b315e

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Preview: https://svelte-dev-git-preview-svelte-16188-svelte.vercel.app/

Nice!

I'll be happy to sunset svelte-ast-print in favour of built-in into the core print() function. 👍
I'm glad the need for it finally reached this point. I'm swamped right now with my real-life stuff, but just in case, both @manuel3108 and @paoloricciuti have access to the svelte-ast-print repository in case I don't manage to announce it on time.

I think this is ready now.

Here is a playground.
This will enable sv to use the svelte compiler directly, instead of doing a bunch of magic to parse and serialize svelte files: sveltejs/cli#751
The first example provided in the playground is from the demo integration from paraglide which i did also prepare in sveltejs/cli#751

Once this gets merged, you could do stuff like this:

import { parse, print } from 'svelte/compiler'

const ast = parse('<Whatever>svelte<span>code</span></Whatever>', { modern: true })
const output = print(ast).code
console.log(output)

The docs are pretty bare-bones, as with the other topics on the svelte/compiler page. But I do think they explain the most important points.

There is one major open point though, which I'm happy to discuss on Friday. It's related to adding new comments to the js-ast for the script-tag. This is currently a flaw in esrap, which we should solve before merging this: sveltejs/esrap#79. Whatever we do in esrap, should probably also be exposed here.

Disclaimer:

• formatting is way from perfect in certain cases, but that's not a problem:
  • we can easily adjust that later on in follow-up prs
  • you should run prettier (or any code formatter) over your files as soon as they got modified. The intent here is not to produce a 1:1 output,
• I'm not sure if we currently support all nodes / types that we have. But support should be pretty good, and it's easy to add stuff later on.

Awesome! I opened sveltejs/esrap#90 as an alternative to sveltejs/esrap#79; should be easier enough to bring either over.

Spotted one thing we have to fix before we can merge this — we mustn't generate self-closing tags for HTML elements. Certainly not the non-void ones. <div></div> and <div /> are not the same as far as HTML is concerned. For void elements it's less clear-cut — <input> and <input /> are equivalent, but only because the closing solidus is ignored. Technically, <input> is correct.

Couple of other nits I'd love to see us fix at some point (though as you say, it needn't block this PR) — multiline blocks ought to have a margin between them:

if (true) {
  console.log('multiline blocks in JS get a margin between them');
}

if (true) {
  console.log('like that');
}

<div>
  <p>but multiline blocks in Svelte...</p>
</div>
<div>
  <p>...don't. It looks very cramped</p>
</div>

And this...

<div data-one="1" data-two="two" data-three="3"></div>
<div data-one="1" data-two="two" data-three="3">text</div>

...gets turned into this:

<div
	data-one="1"
	data-two="two"
	data-three="3" />
<div
	data-one="1"
	data-two="two"
	data-three="3">
	text
</div>

Aside from the self-closing thing, I think this is arguably more conventional — the > of the opening tag at the same indentation level as the <:

<div
	data-one="1"
	data-two="two"
	data-three="3"
></div>

<div
	data-one="1"
	data-two="two"
	data-three="3"
>
	text
</div>

If we do get the formatting looking nice enough, we could add a 'format' button to the playground. that'd be cool